Subject: MIB work items

From: "Peter W. Gayek" <[email-masked]>
Date: Thu, 19 Jan 95 15:44:59 EST

David needed some input on a few of the work items from San Francisco
in order to put out the new draft MIB to be reviewed at the end of the
month.  To keep things moving, I gave him the following input.  You can
comment online here or wait for the conference call.

(1) Flow control objects
      These objects were all messed up (did not distinguish xmit and
      rcv roles or allow to express both xBUSY and pacing support).
      I recommend the following, after some thought:

      dlswFlowCntlSupport (the product's code capability) should be
          split into two objects:
        dlswXBusySupport
          1 - none
          2 - receive only
          3 - send and receive
        dlswPacingSupport
          1 - none
          2 - fixed receiver and adaptive sender
          3 - adaptive receiver and adaptive sender

      dlswAdminFlowCntlMode should be deleted.  The RIG did not define
          a way to signal/negotiate a "preferred" flow control mode
          with a partner DLSw.  So the only value left is to be able
          to force an adaptive receiver box into fixed receiver mode.
          I don't see very much value in being able to do this.

      dlswOperFlowCntlMode should be renamed and moved to be on a
          transport connection basis.  It is possible to be doing
          pacing and enter/exitbusy independently on different TCs.
          Suggested allowable values:
          1 - undefined  (before capex is complete)
          2 - ENTERBUSY / EXITBUSY
          3 - Pacing
          4 - Other  (accomodates vendor-specific mechanisms)

      dlswInitRecvWndwSize is fine as is (with the edits from SF)

(2) Description of dlswStatus
      The status of the DLSw part of the system.  Changing the value fro
      "active" to "inactive" causes DLSw to take the following actions:
         - disconnect all circuits through all DLSw partners
         - disconnect all transport connections to all DLSw partners
         - disconnect all local DLC connections
         - stop processing all DLC connection set-up traffic
      Since these are destructive actions, the user should query the
      circuit and transport connection tables in advance, to understand
      the effect this action will have.

      Changing the value from "inactive" to "active" causes DLSw to
      come up in its initial state (transport connections established,
      ready to bring up circuits).

(3) Enumerated reason code for circuit disconnect

      1 - Received HALT_DL from partner
      2 - Received HALT_DL_NOACK from partner
      3 - Received DISC from end-station
      4 - Detected DLC error with end-station
      5 - Circuit-level protocol error (e.g., pacing)
      6 - Transport connection closed normally
      7 - Transport connection closed due to error
      8 - Operator-initiated (mgt station or local console)

    (discussion question:  should we distinguish for 6-7 why the
     TC was closed and what the errors may have been?)

Peter